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(g) Multiple can control method in a multimedia conferencing systenu 

A method for use in a multimedia conferenc- 
ing arrangement to control multiple concurrent 
cans where each call comprises one or more 
channels. A first call among a first set of user 
stations and a second caO among a second set 
of user stations are merged into a single call 
comprisng a plurality of channels among at 
least three user stations frcun the first and 
second sets. The plurality of channels of the 
single, merged call corresponds to a comtx- 
nation of channels of the first and second calls 
and may include a signalling channel, a voice 
channel, and one data channel for each data 
channel of the first and second calls. The 
method is also applk:able to calls including 
image or video channels. 
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Technical Field 

This invention relates to comnninication con- 
ferencing. 

5 

Background of the Invention 

U. S. Patent 4,905^31, issued to W. F. (jeung at 
aL on February 27, 1 990, discloses a multimedia com- 
munication s^em using a slrrgie packet switching io 
network forthe various media based on what is refer- 
red to as a multimedia virtual circuit A v'fftual circuit 
is a packet-switched communications path between 
two endpoints. A network call set up procedure 
establishes a virtual circuit and an associated virtual is 
circuit identifier based on a destination address. To 
route successive packets, the network needs only the 
virtual circuit identtfier. In a multimedia virtual circuit, 
a virtual circuit is divided into multiple virtual channds 
atthe worfcBtafions. Each channel represents a diffe- 20 
rent infonnatk>n medium and has a sef^rate channel 
Uentffier; the ccHnposrte multimedia virtual cifcuit rep- 
resents the resulting multimedia c£dl. As the various 
multimedia call sources genwate traffic, the works- 
tation mtdtipiexes the packetized traffic onto a single 2S 
network virtusd droulL The destination workstation 
demultiplexes, this traffic t>ack into multiple channels, 
which it routes to a telephone, speaker, file or other 
destination. This process preserves the temporal 
ordering of the infbnmatkan streams so that in a voice 30 
and video call, for example, the voice corresponds to 
the mouth movement in the video picture. The mul- 
timedia virtual circuit also provides a simple way to let 
a multimedia call destination associate the multiple 
media. A single incoming call notiffcatton arrives from 35 
the network to announce a call. The wwkstattons then 
exchange signaling information over a virtual channel 
of the multimedia virtual circuit to set up all the neces- 
sary channels and to route them to the appropriate 
devices. 40 

The Rapport multimedia conferencing system, 
disclosed in the S. R. Ahuja et al. article, The Rapport 
Multimedia Conferencing System," Proceedings of 
Conference on Office Informatton Systems, March 
1983, supports Interacthre, real-time distributed con- 45 
ferences among two or more people Executing on 
personal woricstattons interconnected by separate 
data and voice networks, the Rapport system pro- 
vides basic mechanisms to create, manage, and t^- 
mlnate confmnces. The system provides an 50 
environment in which many types of meeting can take 
place. Including telephone conversatkHis, discussion 
among colleagues, and lectures. Existing workstation 
programs can be used during a conference to produce 
and edit data and displays for conferees. Rapport is as 
designed to help people enmilate fece-to^ace confer- 
ences as closely as possible their workstattons. 
However, the reliance on sepa^te networi^ for the 



different media (data and voice) substandally compli- 
cates the control of confierence calls. Although con- 
current partidpation in many conferences is possible, 
a user is only atde to communicate on one caA\ at a 
time. A Rapport system us^ may participate in many 
conferences concurrently by switching among con- 
texts at the dick of a mouse button. This is equivalent 
to being able to walk In and out of several meeting 
roonrts (and one's office) instantly. It is anticipated that 
this capability will encourage users to keep many con- 
ferences active for long periods of tinte in much the 
^me fashion as the use of screen windows allows 
one to keep nrmny programs and fDes active with the 
present data networks. One such kmg-lrved confer- 
ence might be an intercom connection t)etween a 
ntanager and a secretary. Others might be anxing the 
collaborators in a des^n prcject orthe authors of a 
paper. It is antidpated that once the capabili^for nrujl- 
tipie concurrent calls is provkied. It wQI be useful to 
merge and split such caDs. For example, the manager 
may ask the secretary to jdn a design project confer- 
ence from time to time to assist the project team. The 
effsctive contrd of a plurality of a muitimddia calls 
poses a technical proUem, particularly In the Rapport 
system arrangement comprising several separate 
networks, but also for the system of the above-refer- 
enced U.S. Patent 4,905^1 enr^loying a single net- 
wcvkforall media. 

Solution 

This problem ts solved and a technical advance 
is achieved in accordance with the prindples of the 
invention in a method for controlling multiple concur- 
rent calls where each call comprises one or more 
channels. A first call among a first set of uset stations 
and a second call among a second set of userstattons 
are, for example, merged into a single call comprising 
a plurafity of channels among, significantly, at least 
three user stations from the first and second sets. The 
plurality of channels of the single, merged call conBs- 
ponds to a combination of channels of the first and 
second calls and, ilustratively, may Indude a signal- 
ly channel, a voice channel, and one data channel 
for each data channd of the first and second calls 
(FIG. 1). The method is also ap^^icable to calls indud- 
ing image or vkleo channels. 

In an aiustrative omtxxliment, a user interface is 
provided such that the first call is established in res- 
ponse to user e.g., input via a mouse button, and, in 
addition, representattons, e.g., face teons con'e- 
spondlng to users of the first set of user stattons, are 
diplayed in a window of a display (R6. 17). The sec- 
ond call is established in simOar tohk^n among the 
second set of user stations. The merging of the two 
calls Is effected in response to user input at a user sta- 
tion that is a member of both the first and second sets. 
As a result of the merge, representations correspond- 
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ing tp ttie userstafions of the ftrst and second sets are 
dbplayed in a windorwfor the merged calL In addition, 
representations each oorresponding to one of the 
plurality of <^nels of the merged call are also dis- 
played In the window, icons for a voice channel, a data 
channel being used for a character-tmsed application 
ksh, and a data channel being used for a graphical- 
based application EZ, are niustrated in RG. 19 in a 
representation of a conference room. The data com- 
munlcation applications themselves are displayed in 
other windows. An access control mechanism pro- 
vkjes selective access for a user station to transmit 
Information to and receive Information finom the 
plurality of channels of the merged call. The plurality 
of channels of the merged call comprise virtual chan- 
nels of a nHJtticase connection through a packet 
switching network. A merge request is transmitted 
from from one user station via the network to each of 
the other user stations of the first and second set The 
merging is Initiated in response to receipt of a favor- 
able reply linom each of the other user stations. 

In a method of the Invention, a single call, com- 
prising a plurality of channels, is provided among a set 
of user stations. The shgle caO is split into a first call 
among afirst subset of user stationsand a second call 
among a second subset of user stations. The first call 
includes channels corresponding to a first subset of 
the channels of the single call and the second call 
Includes channels corresponding to a second subset 
of the channels of the single call (RG. 2). 

A further method of the invention is used in an 
arrangement comprising a communication network 
interconnecting a plurdity of user stations. Afirst call, 
comprising at least a voice channel, is provided 
among a first set of user stations, and a second call, 
comprising at least a voice channel, is provided 
among a second set of user stations. One user station 
is a member of both of the fsrst and second sets. The 
one user station enat>le3 a user to communicate via 
both of the first and second calls at the same time. 

Illustrativety, the one user station comprises a 
voice bridge, implemented, for example, using a 
plurality of voice packet/analog voice converters, and 
a conventional analog voice bridge. A user is able to 
conwnunicate on two (or more) calls at a lime. The 
user is able to transmit voice concurrently on the voice 
channels of both of the ftrst and second calls. The user 
Is also able to transmit voice on the voice channel of 
one call and to concurrently receive voice on the voice 
channel of the other call. Further, the user is able to 
receive voice concurrently on the voice channels of 
both of the first and second calls. 

In a further method of the invention, the network 
provides a first call among a first set of user stations 
and a second call anwng a second set of user sta- 
tions. At least one user station, which is a member of 
both of the first and second sets, includes a display. 
Representation conBsponding to the first set of user 



stations art displayed in a first window forthe first call, 
and concurrently, representatkins corresponding to 
the second set of us^ stattons are displayed dis- 
played in a sec^ window for the second caL A user 
5 may record a first call while communicating on a se> 
ond call. 

Drawing Description 

10 RG. 1 1s a diagram Olustrating the merger two, 
multi-channel catis Into a single caS; 
FIG. 2 is a diagram Diustrating the splitting of a 
single, multi-channel call into two calls; 
FIG. 3 ts a diagram of a multicast packet switching 

is network; 

FIG. 4 Is a diagram of an Indi^dual miiticast 
packet switch in the network of RG. 3; 
FIG. 5 is a diagram fllustraUng a strong packet 
sequencing conditton; 

20 FIG. 6 is a diagram Olustrating the packet switch- 
ing process fcx* a multicast connection through a 
multteast packet switch; 

FIG. 7a-RG. 7c Illustrate three data packet flow 
pattems within a multicast packet switch; 

25 FIG. 8a-FIG. 8d are diagrams used in describing 
properties of data packet flow pattems; 
FIG. 9a-FI6. 9c and FIG. 10a-R& 10b are diag- 
rams used In describing properties of vanila mul- 
ticast oonriectkms; 

30 FIG.11a-FIG.11c are diagrams used In describ- 
ing properties of strong multicast connections; 
Ra 12 and RG. 13 are diagrams of two nmil- 
timedia conferencing arrangements (the RG. 13 
arrangement is a particular exemplary embody 

35 ment, referred to herein as conference system 
1000, which implements Illustrative nujltiple call 
control methods of the Invention); 
FIG. U aiustrates the use of the connector and 
the virtual circuit in sharing a character-based 

40 application program; 

FIG. 15 Dlustrates the sharing of a graphical prt>- 
gram by two parties; 

FIG. 16-RG. 24 Slustrate various menus, window 
and Icons for effecting conference calls and 
45 merging and splitting operations in accordance 
with a user interface forthe conferencing arrange- 
ment of FIG. 13; and 

FIG. 25 ilustratss a two-phase protocol used for 
merging and splitting mutti^hannel calls in the 
60 conferencing arrangement of RG. 1 3. 

Detailed Description 

Multicast Connections 

55 ; 

FIG. 3 shows a multk:ast packet switching net- 
worit whtoh consist of multicast packet swildies 
(MPSs) and networic interfaces (NIs). 
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To achieve highspeed transmlsston, the mult)- 
ca^ packet switching network is based on fast packet 
technology (described in J.J. Degan et al., "Fast 
Packet Techndogy for Futures Switches", AT&T 
Techn!calJoumal, Vol. 68, Uo2, p. 36^, 1989), hav- 
Ing thefDltowIng attributes: (a) Link*by-llnk error and 
flow control is eliminated. Thus, the required fielcl in 
the data link header is forthe logbal channel number 
(LCN)» which is used for routing packets through the 
nnilttcast packet swftching network. An LCN for each 
linkvnthin a connection Is decided at connectk>n setup 
time; (b) Edge-to^ge error centred can be Incorpo- 
rated within the multicast packet switching network on 
a per-connection ba»'s; and (c) The multicast packet 
switching network provides internal connection-orien- 
ted services that support high-bandwidth applications 
very efficiently. In such networics, the requked link 
bandwidth and the end-lo-end delay for a nrtuHicast 
application are independent of the number of users. 
Also, the networic performance wiB not degrade as the 
number of users increases. These advantages pro- 
vide a solid foundatton for the multicast packetswitct>- 
ing network as a vehicle for supporting various 
multicast appltcatbns, especially, interactive mul- 
timedia nHilti-par^ conferencing. 

A multicast packet switch is composed of a switch 
fabric, a switdt processor, and switch interfaces (Sis), 
as shown in FIG. 4. The switch fabric is capable of 
duplicating an incoming packet and routlr^ the copies 
to desired outgoing ports. An exemplary nrtulticast 
pad(6t switch is dtsdosed in the U.S. patent appli- 
cation cf K.T. Terasllnna et al., serial number 
07/412.952. assigned to the assignee of the present 
invention. 

[Definition 2.1]: Whith multlF^e inputstreams each 
destined to multiple out^ts, a switch fabric is saki to 
have 

a. the weak sequencing (WS) property, if it only 
guarantees p<Mnt-to-point sequential transfer 
from each input port to any of tts output ports; or 

b. the strong sequencing (SS) propejt^, if those 
output ports recehnng two or more conunon 
Inputs have kientical interieaved packet streams 
with respect to the packet streams from the conv 
mon Input ports. For example, bi FIG. 5, the two 
subsequences of outgoing packet streams at 
svdtch interfaces D and E (or switch int^ces E 
and F) containing {bj and {cj (or {aj and {b}) are 
Identical. 

A multicast packet switch w3l be represented as 
w-MFS (or s-MPS) if swtch fabric has the weak 
sequencing (or strong sequencing) property. 

In general, different links within a multicast con- 
nection may use diffierent LCNs. Thus, each switch 
Interface maintains a packet trandation table (PTT) 
and a multicast control table (MCT) to store routing 
Infonnatbn about those multicast connections. Each 
entry of a packet translation table, indexed by an 



incoming LCN, contains a multicast oonnectnn nunv 
ber (MCN) and a switch header. On the incoming MK 
the MCN field stores the MCN assigned to a multicast 
connectk)n during connection setup, the swftch 

5 header Identifies a set of outgoing links Involved in a 
multk:ast oonnectton, which is used for packet dupll- 
catk>n and routing through a switch fabric. Each entry 
of the multicast control table^indexed by a MCN, con- 
tains the LCN diosen for the outgoing fink within a 

10 multk:ast oonnectbn. 

FiG. 6 illustrates the data packet switching pro- 
cess through a multicast packet switch for a multicast 
connection. An incoming packet accesses the packet 
translation table by LCN a at switch interfeoe A. 

15 Switch Interfece A then replaces LCN a In the packet 
header by the stored MCN m and prepends the stored 
switch header to the packetfor packet duplication and 
routing. Each outgoing packet uses MCN m in its 
header to access the multk:ast control table at the out- 

20 going sw%ch interface and obtains an outgo^g LCN. 
Switch interface Band swieh inter£ace Cthen replace 
MCN m m the packet header by LCN b and LCN c, re- 
spec^y. Rnaliy, the switch header of each outgoing 
packet win be stripped off atthe outgoing switch inter- 

25 face before St leaves. 

{Lemma 1]; Any arbitrary data packetflow pattern 
(DPFP) within a multicast packet switch can be 
achieved. 

<Proof>: Given a set of switch Interfaces, with an 
30 LCN chosen for each switch interface, it is dear that 
the directbn of data packet flaw among these switch 
friterfaces can be controlled by writing suitable Infor- 
mation into their packet translation tables and muiti- 
cast control tables. 
35 RG. 7 ilustrates three natural data packet fiow 
pattems within a multicast packet switch: (a) point-to- 
multipoint (b) polnt-to-muitipoint with upstream 
capabDity. and (c) multipoint-to-muttipoint They will 
be referred to as pattem-1, pattem-2 and pattem-3 
40 data packet flow pattems, respecth/ely. 

The switch processor (RG. 4) establishes snd 
disconnects switched multicast connections across 
the muitteast packet switching network. 

A network interface (RG. 3) provides an access 
45 point to the multicast packet switching network for 
various networics and equipments, 6.g., user stations, 
connected to IL It is responsible for protocol/speed 
converston, packet assembly/disassembly, signaling, 
etc. It also provkles an edge-to-edge flow/enor con- 
so trd across the multicast packet switching networic on 
a per-connectton basis. 

A source-based multicast routing method is used 
to perform multicast connection sehjp. This method 
. can be applied to both switched nmjib'cast connection 
55 setup and multteast connectionless packet routing. 

For each multicast packet switch in the multicast 
packet switching network, several spanning trees 
rooted at this multicast packet switch are generated. 

4 
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A unique global tree number (TN) will be assigned for 
each tree. Based on these trees, multicast routing 
tables (MRTs) are established at each multicast 
packet switch during network initialiration- The ^ze of 
the multicast routing tables depends on the number of s 
multicast packet switches in the multicast packet 
switching network and the number of trees. Therefore, 
a tradeoff between the number of trees and meniory 
space required at each multicast packet switch is 
made. These tables may be updated dynamically. io 
However, it should be done Infrequently. The advan- 
tage of using multiple spanning trees is to provide 
alternate multicast routes such that the connection 
completion rote can be improved. Under nomnal situ- 
ations, the connectton control packetsforestablishing ^5 
or disconnecting a connection progress fonward from 
tiie source multicast packet BwitcAi to the next desti- 
nation multicast packet switches. They may need to 
crankback to tiie source multicast packet switch for 
finding alternate spanning trees when some multicast 20 
packet switeh belonging to the chosen spanning tree 
rejects the new connection setup for some reason. 

The basic connection setup procedure is as fbi- 
lows. When a conne^n setup packet arrives at the 
source multicast packet switch, the switch processor 25 
chooses a tree mmiber, among a set of tree numbere 
which conrespond to those spanning trees rooted at 
tills multicast packet switch, based on a load sharing 
method. Based on the destination set In the packet 
and the multicast routing table indexed by the chosen 30 
global tree number, the switoh processor checks If tiie 
appropriate necessary and sufTicient condittons des- 
cribed in detail herein are mat to detenmine whetiter 
tiie multicast connection ttiat would be established 
would be usable to effect communication in accord- 35 
ance witii a specified transmission matrix and meeting 
a given packet sequendng condition. )f the check is 
positive, the switch processor then partitions tiie des- 
tination set into several subsets; each subset vwll use 
a different outgoing link. By putting ttie chosen tree 40 
number in the packet and masking off all other desti- 
nation addresses In the destination set except those 
in tfie corresponding subset, a modified copy of tiie 
{^ginal connection setop packet is then generated 
and sent to each des^ outgoing link. In addition, tiie 4S 
switoh processor will choose an avaQabte multicast 
connection number (MCN) and send signal packets to 
update the translation taXAes in each involved switch 
interface. When tiie modified packet reaches tiie next 
multicast packet switch, ttie switch processor uses so 
tiie tree number in the packet to Index a multicast rout- 
ing table, does some necessary checking, and tiien 
furtiier partitions the destination subset. This proco*- 
ures repeats untill all the destinations are reached. 

The concept of multicast connections is a natural ss 
extenston of ttet of point-to-point connections. That 
is, a multicast connectton is a logical association 
among a set of network interfaces over which all pack- 



ets following the same route, need not carry complete 
destination addresses and arrive in sequence. Based 
on different requiremente, four flavore of multicast 
connections are defined over an aristtrary mdticast 
packet switching network: vanilla multicast connec- 
tions (VMCs). multicast virtual drcults (MVCs), strong 
multicast connections (SMCs) and strong multicast 
virtual circuite (SMVCs). Roughly speaking, vanUla 
multi<xtst connections and strong multicast connec- 
tions only provkle netwK»k-layer connection-<»iented 
services to ttie usere, and packet loss is allowed. 
They depend on the usere' transport layer to execute 
error control, if necessary. On the other hand, multH 
castvirtual drcuSs and strong multicast virtue circuits 
provide netwoik^aye- virtual circuit services to ttte 
usere, whidi ensue reliable packet transfer. Theref- 
ore, error control &i the transport layer not neces- 
sary. 

Four flavors of multicast connections are defined 
on acydie subgraphs of tiie graph representing a mul- 
ticast packet switohtng networks. Acydte subgraphs 
guarantee that each multicast oonnedion contains no 
loop and every pack^ wiil reach Hs destination(8) in 
finite time and low delay. 

[Definition 3.1]: 

a. An artsOrary multicast packet switohing network 
is represented by a graph G = ^,E.L}, where S is 
the set of all multicast packet switches, E Is the 
set of all netwoHc interfaces, and L is ttie set of all 
linte- 

b. G = {S, E, L} represente an acydto subgraph of 
G, whksh interconnecte all networic Interfaces in a 
subset E of E via a subset! of S and a subset L 
of L Any link I to L cute G Into two disjoint sub- 
graphs G1.0 and G^tf. Let^^and Ij^ be two disjoint 
subsete of E. which contein those network inter- 
faces in ^ and Gu> respectively. 

c. Each networic interiiace contains a sender corrv- 
ponent (SC) and a recewer component (RC) ttiat 
sends and receives packete, respectively. Let SC 
i and RC i represent tiie sender component and 
the receiver component of network interface I, re- 
spectively. 

Consider an an art)itraiy acydic subgraph G of G. 
According to Ijemma I, witti an LCN chosen for each 
switoh niterface, any arbitrary date packet flow pattem 
within each multicast packet switch in S can be 
achieved. Interconnection of these indhndual date 
packet flow patterns via the links E constitotes a date 
packet flow pattem on G. The flow direction m each 
link is determined by two indhridual date packet flow 
patterns at ite ends. Witii a date packet flow pattem 
•witiiln each multicast packet switches being exem- 
plified, link 3 has a bWkectional flow in RG. a{a) and 
a unidirectional flow in FIG. 8(c). The corresponding 
transmission matrices are given in FIG. 8(b) and FIG. 
8(d). 

ILemma 21:Given a G, any date packet flow pat- 
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tam constnicted on G has the following properties: 

a. Only a single LCN is assodated vrith each fink 
InL 

b. The data packet flow pattern satisfies the weak 
sequenctng (WS) comfflion, that Is. potnt-^opoint s 
sequential packettransferfrom any network inter- 
face In to each of Its receMng network inter- 
face(s) is guaranteed. 

<Proof^:(a) is dear since, during the construction 
of a data packetflow pattern on G, a conmon IXN can 
be chosen for the two switch interfaces at ends of 
each link in L (b) hdds since each multicast packet 
switch has at least the weak sequendng property. 

[Definitton 3^]: 

a. Given a E the sending/receiving relatk>nship 
among all network intofaces In £ is represented 
by a N-by-N transnrnssion matrbc TM(^, where N 
is the nuntberctf network Interfaces in E TM(£)DJ] 
is 1 if RC J receives packets from SC i, and 0 
othenvise. 

b. Given two subs^ X and Y of E the submatrbc 
TM(X,Y) is obtained firom TM(E) by rotain^g only 
those sender components In X an£ ordy those 
receiver components in Y. Ljet TM(Ei^ Ei^ and 
TM(^^, EiJ be represented by TMi^ and TMi^^, 
respectively. _ _ 
Given a data packet flow pattern on G, at TM(E) 

can be easily obtained by tradng data packet ftows 
from each network interface In E. 

By imposing differejit requirements on da!ta 
packet flow pattems on G, four flavors of multicast 
connectkins are defined. _ 

[Definition 3.3]: Given a G, a data packetflow pat- 
tern on S is a vanilla multicast connection, if it satisfies 
the mutticast condition: There exists at least one net- 
work internee In E firom which the packet stream Js 
destined to two or more network interfaces in E. 
These network interfaces are referred to asmulticast 
sources (MSs). The representatk>n VMC(G} will be 
used to show the relattonship between a vanilla mul- 
ticast connectton and its associated G. 

The multicast condition Implies that (1) At least 
one multicast packet switch in 5 >m1I duplicate pack- 
ets; and (2) The TM(E), obtained from arty VMC(S), 
has at least one row containing two or more I's. From 
this point on, only TM(^'s having at least one row 
containing two or more i's are considered. Given a G, 
a TM(E) with the weak sequencing condition may not 
be satisfied by a VMC(G). _ _ 

[Theorem 3.1]: Given a G, a TM(E) with the weak 
sequendng condOion can be satisfied by a VMC(G), 
if and only if it has the following VMG property: For any 
link I in U if Th^a^ (or TM|^ contains two or more 
norvzero rows, these raw must be identical. In other 
words, every sender component in ^ (or send- 
ing packets to the receiver components in E|^ (orjm) 
nHJst have klentical destinatbn subsets of ^ (or ^ J. 

<Proof>: The sufficient condfUon is shown by con- 



tradiction. Assume that there exists a link I'm E so that 
TMgyi contains different non-zero rows. This Implies 
that there exist sender components e^ mtd ez in E|^ 
and receiver components e% and 04 in E|^ such that 
TM({ei,e2},{e3.ei}) Is either RG, 9(a) or (b). In RG. 
9(a), SC ei sends packets to both receiver compo- 
nent da and 84, and SC 02 only to RC 03. In FIG. 9(b), 
SC ei only sends packets to RC ea. and SC 82 only to 
^C 64. Since G is an ac^k: graph, there exists a MPS 
s in G14 80 that packet flows from^SCs e^ and 02 will 
enter its sw%d) interfiace A via link I, as shown in RG. 
9(c), and packet flows destined to RCs 03 and 64 vnll 
leave from switch interfaces B and C, respectively. 

With a single LCN assodated with link I, packets 
fron SCs ei and 62 will have the s^e LCN in their 
headers when they are sent over llnkl. Since one LCN 
only indexes one entry in the packet translatton table 
of switch interface A, packets with the same LCN can- 
not be duplicated and routed to different subsets of 
outgoing switch Interfaces. Therefore, the desired 
data packet flow pattern wHhln MPS s to support the 
submatrtces in FIG. 9(a)-(b), can not be achieved. 
This implies that the TM(E) can not be Implemented 
by any VMC(G). The above condusion is also true 
when TMi4^ contains different non-zero rows. 

Next the necessary oonditbn is proved. lj»t Eu,i 
and Eu^ (or Ed,i and be two subsets of E|^ (or 
Ei^, so thatTM(E^i, Eu.i)(orTM(Ea^, E^) contains 
all the 1's in TMi^d^ (or TMi^^u)* The corresponding 
packet flow models of TM(E<t,i>Ea,i) an^TM(E^Ed^ 
are shown in RG. 10, in which MPSs Si and S2 both 
have pattenvl data packet flow pattems. Let LCN n 
be chosen for link I, then padcets from each sender 
component in Eu^ and E^^ wil use LCN n when they 
are sertt over link I. To achieve these two data packet 
flow pattems, let the routing field in the switch header 
entry of the packet translation table at switch Interfece 
A (or SI B, resp.), indexed by LCN n, Mentiiy a set of 
outgoing links from which packets are transmitted to 
the receiver component in E^ (or E^^. 

Three natural vanilla multicase connections over 
the multicast packet switching network are given 
below. 

a. Point-to-multipoint (Pattem-1): There Is only 
one multk:ast source and each mdticast packet 
switch in the vanlila mutticast connection has pat- 
tem-1 data packetflow pattern. 

b. Point-to-multipoint with upstream capabDIty 
(Pattem-2): There is only one muiticaste source 
and each multicast packet switch in the vanilla 
multicast connection has pattem-2 data packet 
flow pattern. 

a Mdtipoint-to-muitipoint (Pattem-3): In this vani- 
lla multicast connection, each network Interface is 
a multicast source and each multicast packet 
switch has pattem-3 data packetflow pattam. 
Most data applicattons require reliable communi- 
catton. To provide a network-based edge-to-edge reli- 
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able service to those multicast applications that 
require completely error-ftee transmission and that do 
not employ some higher-layer error control fwotocd. 
the multicast viitual circuit is introduced. 

[Definition 3.4]: A multicast virtual cfeuit is a vani- 5 
lla multicast connection which also satisfies the reli- 
able condition: Polnl-to-point reliattle packet transfer 
from any networic interface to each of Its receiving net- 
work interfaces Is guaranteed. 

There are two issues assodated with a multicast io 
virtual circuit 

1. Since a vanilla nuilticast connection may have 
multiple senders, a multipoint-to-multipoint error 
control protocol must be exercised among all net- 
work interfeces. 

2. Given a TM(^ w^ the >^nia multicast con- 
nection properties, a VMC(G) can be set up to 
meet the desired Inf6rmatk>n flow relationship 
among users. However, this VMC(5) is only con- 
cemed wim transmission of data (or Informatton) 
packets, and there may not ex^ paths In it for 
returning acknowledgements (ACKs). 
One approach to address the second Issue is 

described below. If the VMqO) of a ghfen TM(E) also 
provides paths for returning acknowledgements, itwill 
be used to transmit both data and acknowledge- 
ments. Otherwise, a_TM'{E) is obtained, where 
TM'(E)Rfl «s 1 if TM(E)[i41 or TM{E>D.i] is 1. If the 
TM'(E) Still has the vanilla multicast connection 
properties, a new VMC(G) is then set up to support the 
desired informatton flow relationship represented by 
the TM(I) and provide necessary acknowledgement 
paths, in both cases, sonne network interfaces may 
receive undesired data packets and/or acknowledge- 
ments. Therefore, two address fields-the addresses 
of the sending network interface and the receiving 
network interface-are reserve in the error control 
header so that each network interface can discard 
undesired Incoming packets. The second field is used 
only by the acknowledgements. 

A vanilla multicast connectk>n and a multicast vir- 
tual drcuit are not concerned with the sequencing 
relationship across multiple senders. Although most 
multicast applications can be supported by a vanilla 
multicast connection or a multicast virtual circuit, 
some multicast applications may request the miriti- 
cast packet switching network to provide a multicast 
service which maintains the sequencing relationship 
across multiple senders. A strong multicast connec- 
tion and a strong multicast virtual circuit are intro- 
duced to provide a netwoilc-based strong sequencing 
mechanism to those multicast applicattons that 
require strong sequential transmisskin and that do not 
employ some higher-layer strong sequencing pro- 
tocol. 

peflnition 3.5}: A vanilla nmjltlcast connectk>n is 
a strong multicast connectton, if ft also satisfies the 
strong sequencing (SS) condition: the sequence of 



packet streams arriving at a set of nebmrk Interfaces 
with two or mora oomrrwn multicast sources are kian- 
tical with respect to the input streams from corranon 
multicast sources. 

To investigate the relationship between tranmis- 
sk>n matrices with tite strong sequencing ocmdition 
and strong najltica^ connections« consider those 
transmisskm matrices which have the vantUa multi- 
cast connection properties stated in Theorem 3.1 and 
can be implemented by a vanlla multicast correction. 

[Definition 3.6]: 

a. Ghren a matrix, two columns (or two rows) 
a and p are said to be coupled, cdimui (or row) 
a contains at least two 1 's at tiie same row (or col- 
umn) position as column (or row^ p. 

b. A matrix with at least two coupled oobmms is 
said to have thestrong couplir^ property. If Bs col- 
umns (or rows) can not be partitioned into two dis- 
joint subsets such that ttiera exists one column 
{or row) in each subset and these two columns (or 
rows) are coupled. 

c. A TM(E) having ttie vanilla multicast connec- 
tion property and at least two coupled colunvis is 
called a coupled transmissbn matrix represented 
as CTM(E). 

It is dear that for each non-CTM(E) witti ttie vanW 
lla multk^ast connection property. Its assodated 
VMG(5) isa SMC(G). From thte point on, consider 
only CTM(E)s. The pwoblem is summarized below, 

[Problem 3.1]: Given a GTM(^, find the sufficient 
and necessary condition such that its associated 
VMG(G) is also a SMC(G). 

Based cm Defin9ion 3.5, tiie strategy to sdve 
Problem 3.1 is to find out all those subsets of receiver 
cwnponents which have respective two or more com- 
mon sender components and then check tiie strong 
sequencing condition foreadi subset separatdy. By 
using the following partition metiiod, a CTM(E) can be 
partitioned into a number of sut^natrices which have 
eittier no coupling property or the strong coupling 
property. Each submatrix corresponds to a partial 
packet flow^of the associated VMC(G). 

[GTM(E) Partition Method]: Let 0_be Initialized to 
indude ^1 the columns of the CTM(£). The disjoint 
subsets {C| j=0, nr)(>»1)) of C can be generated 
from the following steps as C shrinks to an empty set 

Assure tiiat the subsets Q, are already 
non-empty and the subset C| is empty. 

Step 1: 

If C contains only one cdumn, then nwve the 
remaining column from 0 to Co. In any case, stop 
if C is empty. Otiienvise go to Step 2. 
Step 2: 

Find a column with tiie largest number of 1 's, say 
c. from C. Move c from C to Cj. 
Step 3: 

For each cdumn c in 0, repeat the following pro- 
cedtffe: 
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{If there exists a column in so that these two 
columns have the coupling property, then move c 
firDmCtoC|.} 

Step 4: ^ ^ 

If C) contains only c then jnoevB c from C] to 0^. 

Qo back to Step 1. 

Let be the set (tf receiver components conre- 
sponding to those columns In Clearly. ... 1^^ 
are disjoint 

By using simOar steps as those above, the rows 
of each submatrix TM(E Erj). I^i^m, can be par- 
titioned Into a^number of disjoint subsets {R| I » 0, 
n ^1)}. Let represent the set of sender a»npo- 
nents corr^pondlng to the rows In R| and TMy repre- 
sent the submatrix TM(E»j,Erj). Qearly, ^. 
are disjoint 

Co and Ro may be emp^ however, Ct and Rt 
always exist by the definition of CTM(E}. Based on 
Definition 3.5, it is dear that the strong sequencing 
condition of the CTM(E} is satisfied , If and only if the 
strong sequencing condition of each sutHfnatrix 
obtained In the partttfon algorithm is ^tisfled. Since 
TM^EEt^ and TMoji 1^^, If they esdst, do not have 
the coupling property, the packetfiows corresponding 
to these submatrices are ignored whQe the strong 
sequencing condition of the CTM(E) Is checked. How* 
ever, each TMij, 1:^:5n, 1^|^, has the strong cou- 
pling property. Therefore, to deal with Problem 3.1. 
consider these TM{j,1^£n, 1^m, and deal with 
their strong sequencing conditions separately. Note 
that each TM^ has the ^nilla nmilticast connection 
property since the CTM(E) does. Depending on the 
type of multicast packet switohes, the Gufflct^t and 
necessary cond^on that the strong sequencing con- 
dition cf a TMy can be satisfied wSi t>e different The 
following definitton is needed for describing the main 
results which are summarized in Theorem 3.2 and 
Theorem 3.3. 

Pefinitlon 3^: Any link I in C cuts G into two dis- 
joint subgraphs and G^^ Let and con- 
tain those sender oomponents^tn Gt^ and G|^, 
respectively. Also let E^^u andj^riu contain those 
receiver components in Gi^ and G|^, respectively. 

[Theorem 3.2]: Assume aD the mtdticast packet 
switdies are w-MPSs. For any given TMg, 1£i^, 
l£{£m, its strong sequencing condition can be satis- 
fied, if and only if, there exists an inter-MPS link in C 
suc^that If all the sender components In E.^ are in 
or (Gf^), then^l the receiver components in E^j must 
be inGj^{orG|^. 

<PrDof>: Since w-MPSs only have the weak 
sequencing property, it is clear tiiat the strong 
sequencing conditton among the receiver compo- 
nents in can be satisTted if and only if these 
receiver components receive packets via a single link, 
where all packet streams originating from the sender 
components in ^ are multiplexed into a single inter- 
leaved packet stream. In this case, the value of each 



element in TMy is 1 , since TMjj has the vanilla multi- 
cast connection property and ttte strong coupling 
property. 

[Theorem 3.3]: Assume all the multicast packet 
5 switches are s-MPSs. For any given TMg,1^^, 
1^m, its strong sequencing condition can be satis- 
fi^, if and only if, for any inter-MPS link I In E, there 
do not exist a sender ccmiponent and a receiver conv 
ponent in ^ and a sender component and a receiver 
10 component in G|^ such that these two receiver com- 
ponents have these two sender components as oc»n- 
mon nrtulticast sources. In other words, ttiere dp not 
exist four respec^e non-empty subsets, say E^xuii* 
E^M»*_Erjxu and E^j^^, of the sets ^ja* ^:xa 
IS and Erjji^.^su(^ tiiat ttie value of each element in 

TM({EauutE.Aw}, {Erj4^Euj4}) is 1- 

<Proof^: When the sender components in £.,1 and 
the recover components in l^j are connected to the 
same multicast packet switch, tiie claim Is true since 

20 tite 8-MPS has ttie strong sequencing property. 
Therefore, it suffices to prove the case when the sen- 
dercomponents in and the receiver components 
in Efj aro connected to the same multicast packet 
switches. Since TMg has the vanilla multicast conneor 

25 tion properties, FIG. 11(a} depicts an equivalent two- 
MPS model witii respect to each inter-MPS link 1. 
Multica^ packet switches 1 and 2 represent the two 
multicast packet switches which link I connects. The 
sender components in E.^ and ttie receiver compo- 

30 nents in E^jji^u are connected to rmjitteast packet 
switch 1 , and ttie sender components in and ttie 
receiver components in Efjj^ are connected to multi- 
cast packet switch 2. 

_ The packet fknv model conresponding to TMdS^ 

35 Bf^j^ is shown In FIG.1 1 (b). This Is equh^ent to ttie 
case that the sender oomponents in end the 
receiver components in Erjj^ are all connected to mul- 
ticast packet switch 1, and therefore, the strong 
sequencing condition among the receiver compo- 

40 nents in with respect to the common sender 
^xnponents in l^is satisfied. Simaarty, by removing 
Erjj^i E^4 and from FIG. 11(a), respectively, 
the strong sequencing condition among tiie receiver 
components in^^witii respectto the common sen- 

45 der components in E.^. ttie strong sequencing condi- 
tion among the receiver components In Erj with 
respect to the common sender components in E^^, 
and tiie strong sequeridng condition among the 
receiver components in Erj wrtii respect to the conrv- 

so men sender components in are also satisfied. 
Therefore, ttie only remaining case to check Is when 
there exists at least one element in each of four sets 
— EsAi,u> Es,Mi(t> ^ii^ ^d E,,ui^, such that these 
. receiver components have these sender components 

55 as common multicast sources. 

The necessary condition Is proved first For any 
inter-MPS link I In C, suppose there do not exist a sen- 
der component and a receiver component in ^ and 
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a sender componsnt and receiver component in 
such that these two receiver components have these 
two sender components as common multicast sour- 
ces. This implies that the above remaining case does 
not exist Therefore, the strong sequencing condition 
of the TMu is satisfied. Next, the sufficient condition 
is proved by contradiction. Consider Ra 11(c), in 
which sender component A, sender component B, 
receiver component C and receiver component D are 
in E^^, EtM* Efii^ ^jw- respectively, and sen- 
der components A and B are common multicast sour- 
ces to recehrar components C and D. If each of sender 
ccffnponents A and B sends a packet receiver compo- 
nents C and D at the same time, then receiver conry 
ponent C (or receh/er component D) wOl receive the 
packet from sender component A (or sender compo- 
nent 8) first Therefore, receiver cmponents C and D 
will not receive kientical interieaved packet streams. 

[Defkiition 3.8]: A strong multicast virtual circuit is 
strong mulUcast connectton which also satisfies the 
reliable conditton; a set of network internees vtrith two 
or more common multicast sources v^i receive iden- 
tical Interleaved packet streams with respect to the 
input streams from common multicast sources. 

By executing nrttJltidestinatton enor control 
among all network tnterfeces in a strong multicast 
connectk>n, some retransniitted packets may exist 
Without other means, each receh^er component may 
put an original packet and a retransnrutted packet 
coming from different multicast sources into different 
order, and the strong sequencing condition is vk>l- 
ated. To solve this problem, each packet in a strong 
multicast virtual circuit carries a global tkne stamp. 
Time-stamp ordering assures that the strong 
sequendng conditk>n among all the receiver compo- 
nents In a strong multicast virtual circuit is satisfied. 

Various flavors of multicast connectbns provide 
various kinds of multicast services to users. A multi- 
cast application (MA) is an end-user's use for a mul- 
dcast service or a coiiection of multicast services. To 
achieve service integration, a multicast application is 
viewed by the users as an Integrated service. 

The single-media multicast applicattons, such as 
multi-destinatbn file transfer, voice conferencing, etc. 
are generally supported by a suitable flavor of nujlti- 
cast connection. However, for those multimedia mul- 
ticast applications (MMAs) involving two or more 
media, they may or may not be supported by a single 
multicast connectksn. Conskler a multi-party interac- 
tive debugger. Two different scenarios are shown in 
FIG. 12 and FIG. 13, respecth^ely. Each multimedia 
workstation (MMWS) contains a tenminal (e.g.T1)and 
a voice bndge (V6) and is connected to a separate 
network interface. In FIG. 12, the editiir program used 
for file debugging is a network s^er in an intelligent 
server node (ISN). Multiple multicast connections are 
used The dashed lines interconnecting the editor pro- 
gram and the three termhals represent a pattem-2 



multicast virtual drcuit with the intelligent server node 
as the multicast source; the dotted lines interconnect- 
ing the three voice bridges represent a pattem-3 vani- 
lla nrrutticast connection. In FI0.13, the ed&or program 

6 reskies in multimedia wcHkstatkm 1. As before, the 
users can request multiple multicast connectkms to 
support the multinfedia multteast applicattons; or an 
alternative, the users may request a single pattem-3 
vanOla multicast connectton for both data and vok;e. 

10 The latter results in a multimedia rrailtk:a^ conneo- 
tk>n, in which two media share the same logk»l chan- 
nel number and are distinguished tyy diffmnt channel 
numbers. Its advantage is that the oonnmitton setup 
is done only once. Since the data are also sent via the 

IS pattem-3 vanaia multicast oonnec&ont multsnedia 
workstation 3 (or multimedia workstation 2) needs to 
discard those Incoming editcr-program-destined 
editor commands generated at multimedia works- 
tation 2 (or multimedia woikstatton 3). This data- 

20 packet^iscarding is effidentiy demented in 
hardware. Multidestinatbn error control for raliai>te 
data is executed atthe multimedia wofkstations rather 
than the network interfeces. The voice sharing the 
same multicast connectkm with the other media 

25 shows an advantage of using distributed voice 
bridges. 

In summary, the number of midtteast connecSons 
needed to support a given multimedia ntulticast appit- 
catk>n generally depends on the locatk>n of serveis 

30 and thelrrelationships.Fortheiocai servers, such as 
the editor program and the vok» bridges In FIG. 13, 
reskling in the multimedia workstations, a single mul- 
ticast connection or multiple multicast connections 
can be requested to support the communication 

35 among them. For the network servers, reskiing in the 
networic interfaces or the intelligent server nodes, 
their locations are generally transparent to the users. 
Therefore, the users may need to request a separate 
multicast connectton for each independent network- 

40 based service. 

Multimedia Conferencing 

The description of multimedia conferencing 
45 which follows is based on one particular exemplary 
embodiment, refenred to herein as conference system 
1 000, shown in the diagram of FIG. 1 3. Computer sup- 
port for group work can primarily address either 
asynchronization interaction or simultaneous (real- 
50 time) interaction anrang usm. Bectronic maD is an 
example which primarily addresses asynchronization 
interaction among users. Such systems are most use- 
ful when each user works according to their own 
schedule. For some sSuations. lOce crisis handling, 
55 : real-time Interaction is essential and more productive. 
In a real-time computer based conference, people can 
share information simultaneously through their per- 
sonal computers. The recent advancements in high 
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speed networks and high perfbnnance workstations 
nnake it easier for users to have real-time multimedia 
communications. The medium can be voice, ^erao- 
tive data. Image and videa 

There are several existing real-time conference s 
systems. Some of them, e.g. as disclosed In L Agul- 
lar, et al, "Architechire for a Multimedia Telecon- 
ferendng System." Proce^ings ACM SIGCOMM'SS 
Symposium, Augu^ 1986, K C. Forsdick, "Explor- 
ations In Real-Time Multimedia Conferencing," Pro- io 
ceedings of tfie 2nd International Symposium on 
Computer Message Systems. IBP, Septeml^er, 1985, 
A. Poggk), et si, 'CCWS A Computer-Based, Mul- 
timedia Information System," Computer 18, 10, 
October 1985, are constructed as specialized prog- is 
rams distributed among the conferees' computers. 
GeneraDy these spededized programs can not Invoke 
other appiicattons. Consequently, pre-existing appli- 
cation programs had not to be modifled for each con- 
ference systera 20 

Conference system 1000 (FIG. 13) and a few 
othersystems, e.g. as disdosed in K.A. Lantz, "An Ex- 
periment in ^tegrated Midtinrtedia CortferencIng", 
Proceedings of the Conference on Computer-Suppor- 
ted Cooperative Work'86, December, 1986, S.R. 25 
Ahuja, J.R. Ensor, and D.N. Horn, The Rapport Mul- 
timedia Conferencing System," Proceedings of Con- 
ference on Office Informatten Systems, March, 1988, 
allow any pre-existing apfrflcattons, written for a sin- 
gle-user environment to be invoked from the within $0 
fram&workof a conference. These pre-existing appli- 
cations, which produce useful data to a collatx>ration. 
eani}e invoked vnthoutn>odlfications. These systems 
also allow progranvners to develop typical appli- 
cations without having to deal explicaty with the con- 35 
ference issues. 

Another characteristic of conference system 
1000 is that ft is based upon fast packet network 
technology. The transport layer and network iayer 
software in system 1000 can support multimedia 40 
packets (voice, data and image) going through a 
single packet network and can preserve temporal 
synchrDnlzation among drfferent media. Temporal 
synchronization is important for real-time mult&nedia 
communlcatton. For example, a conferee may high- 45 
light different parts of a text file sequentially whie 
making voice comnnents on highlighted text The high- 
lighted text and the voice comments should appear 
synchronously at ail conference workstatbns. System 
1 000 can also record vokse and data Into a multimedia so 
file with temporal synchronization preserved. The 
recorded fOe can be reviewed by a user asynchron- 
ously or played back in a real-time conference. Voice 
annotation on a recorded fie te also supported in sys- 
tem 1000. A user may record a first call wh3e conv 55 
municating on a second call. 

In addition to invoking pre^isting applications 
and recording a conference, system 1000 also sup- 



p<Nts changing conference configurations dynamo 
cally. A conference has two basic elements: con- 
ferees and shared applications. A conference 
configuratk>n is changed by changing these two ele- 
ments. In system 1000, a workstation may have mul- 
tiple conferences at one time. A conference 
configuration can be changed t>y adding or deleting 
applications to a conference dynanmcaOy. It can also 
be changed by merging two conferences Into one con- 
ference or splitting a single conference into two con- 
ferences. Thus, the conferees in the resulting 
conference are changed. 

Usually when an applicatk>n Is invoked In a con- 
ference, it should be shared t>y all conferees in that 
conference. But in some situations. It may be desir- 
able to restrict particular conferees from accessing 
the shared application data (either Inputting com- 
mands or seeing outputs). The abiity to change the 
conf^nce configuration and the ability to control 
access to applications greatly increase the 1leKa>3ify 
of real-t^ desktop conferences. 

In the descriptton whbh foUows, a graphical user 
interface (Ul) is presented which allows users to per- 
form these conference functions: setting up a confer- 
ence, adding (or deletmg) applicattons. controlling the 
access to an appllcatton, recording a conference, and 
merging {ot splitting) conferences. 

The graphical user interface Is based on an 
important idea-the conference room notkxi. A confer- 
ence room is where the conferees meet and see the 
shared application. If an application Is moved Into the 
conference room, it will t>e seen and be used by the 
conferees inside the room. If an appiicatkm is moved 
out of the room. It will no longer be shared by the con- 
ferees. The configuration of a conference is the con- 
tents of the room; the conferees in the room and the 
applications in the room. For any conference, there 
must be some rules conceming who can speak when, 
who has access to sensitive data, etc. This is referred 
to as access contrd. Conferees and applicatkms in 
one room may t>e moved to merge witii another room 
to fonm a joint conference. A joint conference may be 
split into two separate conferences. In the fdlowing, 
basic medianisms for setting up a conference and an 
application are described first The use of menus and 
buttons in the III to perform various conference func- 
tions Is then described in dotal. 

In conference system 1000, tiie multimedia vir- 
tual drcuit as disdosed in U.S. Patent 4,905,231, 
Issued to W.F. Leung et al. on February 27, 1 990, and 
in W.F. Leung, G.W.R.Luderer, M.J. Morgan, P.R. 
Roberts, and S.G. Tu, 'A Set of Operating System 
Mechanisms to Support Multimedia Applications,* 
; Proceedings of 1988 International Zurich Seminar on 
Digital Communications. March 1988, provides net- 
work layer and transport layer Interfaces to the ses- 
sion layer. One Important charadenstic of the 
multimedia virtual c'rcutt is that all of tiie media invol- 
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ved in a call are multiplexed Into a single virtual circuit 
The network layer deals with the multimedia virtual 
circuit as a whole. In the transport layer, the virtual cir- 
cuit Is divided Into multiple channels, where each 
channel transports one medium. The primary objec- s 
tive of multiplexing multiple channels into a virtual cir- 
cuit is to provide tmnpcual synchronization and 
coordination for a multimedia call. 

in system 1000, each conference has one virtual 
circuit connection. To create a conference, the ses- io 
sion layer software first creates a multicast (or point- 
to-point) vbtual circuit to connect to remote conferees. 
The newly created virtual circuit has one signaBing 
channel- The session layer uses thfe signalling chan- 
nel to negotiate with its counterparts to agree on the is 
successive channels and applications. In system 
1000, one channel is dedicated to one application. 
Multiple applications (channels) can be created for a 
conference. The phone device is treated as an appli- 
cation in the conference nriodel. Data applications can 20 
be one of the three types: the traditional character-ba- 
sed application programs, the X-based graphical 
based programs and ^cial conference programs. 

For traditional chEffSCter-based applications pro- 
grams, such as ksh, a driverreferred to as a connector is 
(disclosed in W.F. Leung, G.W.R. Luderer, M J. Mor- 
gan, P.R. Roberts, and S.C. Tu, • A set of OperaUng 
System Mechanisms to Support Multimedia Appli- 
cations, "Proceedings of 1988 International Zurich 
Seminar on Digital Communications, March 1 988), is so 
used for interprocess communication. It provides 
flexible tnterconnec&^9y that can multicast data from 
a source to several selected destinations and concen- 
trate date from several sources to a single destination. 
R6. U illustrates the use of the connecto* and the vir- 
tual circuit in sharing a character-based application 
program (bin/lcsh) by two parties. The process devp is 
needed for transferring a character stream between 
drivers. Itisimportenttonotethatonlyonecopyofthe 
program Is executed per application shared by a con- 
ference. This implementation of sharing character-tea- 
sed applications allows all parties to input commands 
to the application simulteneoulsy. 

In addition to traditional character-based appli- 
cations, ^phical applications based on the X win- 
dowing system (disdosed In R. W. Scheifler, and J. 
Gettys, "The X Window System," ACM Transactions 
on Graphics , AprS, 1986), can also be invoked in our 
conference system without modifications. FIG. 15 
Olustrates the sharing of a graphical program xprog by 
two parties. The X window ser/ers and xpmg are 
unmodified. The pseudo server performs necessary X 
resource identifier translation. The pseudo servers at 
the stetions which do not nin the application program 
perfbnn the translation. Pseudo servers also oontrof 
the flow of X evente from X servers to the application 
program. Unlike the implementetion of character-ba- 
sed applications, this implementation only allows one 



party to input at a time. If party 2 has the control to 
input, then the pseudo server will take the event 
stream only from party 2 and feed it to the application 
program. 

Date applicatton programs designed specially for 
collaborative work can also be integrated into system 
1 000 as long as they use the X windowing system and 
the multimedia virtual drcuit as the transport vehicle. 
As an example, a cut-paste program in system 1000 
allows conferees to share images from woikstetion 
displays. When a cut-paste application is created, 
each stetion runs a copy of the cut-paste program. 

Voice applications (phone) are different ftom date 
applications. Except for voice recording, voice pack- 
ets are transmuted to and from the interface hardware 
directiy without gdng through the user space. 

As steted before, one conference has one vktual 
circuit connedion. A conference may have multiple 
conferees and nmittiple appik:atiMis. To charge a 
conference configuration, any conferee can dynani- 
cally add or delete an application. When en appln 
cation is created for a conference, it is shared by all 
the conferees unless access right are restricted. In the 
present embodbnent, two conferences can be 
merged into one conference. When two conferences 
are nnerged, two virtual drcuKs are merged Into one 
virtual circuiL A conference can be also be split two 
conferences such tiiat each conference has a sepa- 
rate virtual circuit 

Merging and Splitting Multimedia Calts 

The merge operation enteiis combining two 
MMVCs (multimedia multicast virtual circuits) ^to one 
MMVC (FIG. 1). The set of destination end pointe of 
tiie resulting MMVC Is tiie union of the destinations in 
the two original MMVCs; after merging MMVC 3 and 
MMVC 9 \he resulting MMVC 12 has destinations A, 
B, and C. 

Each of the original MMVCs contains one signal- 
ling channel plus other application channels (voice, 
date, or image). The resulting merged MMVC con- 
tains one signalling channel plus the sum of all appli- 
cation channels. That is, if X and Y are the numbers 
of application channels in two MMVCs to be merged, 
tiien ttiere w3l bo X + Y - 1 application channels in the 
resulting merged MIWVC, FIG. 1 shows that worics- 
tetion B has a voice channel and a new date channel 
tiiat did not exist before the merge, and woricstetion C 
has a new date channel. 

in the present embodiment, a conference is not 
allowed to have more than one phone. This issue 
arises when two conferences, each witti ite own 
phone, are merged. At the session layer, each confer- 
ence is supported by one MMVC. When two confer- 
ences are merged, their corresponding MMVCs are 
merged at the transport layer. 

In alternative embodknente, applications may 
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requtre multiple voice channels. Therefore, this Issue 
is resolved at the sessbn layer. It is the session 
layo's Job to dose one of the voice diannels after a 
merge of two MMVCs each containing a voice chan- 
nel. Of course, the conferees need not be aware of s 
these details. To them only one phone appears in the 
conference room after a me^e, as Is expected. 

When one MMVC is spm into two MMVCs (RO. 
2) the session layer specifies the destination end 
points and the application channels that will exist in io 
the resulting MMVCs. Each of the two resulting 
MMVCs wni have a subset of the original application 
channels plus one signalling channel and a subset of 
the original destination end points. It is further 
required that each destination end point be a member is 
of at least one of the two resulting MMVCs. Similarly, 
each application channel should appear h at least 
one of the two resulting MMVCs. in other words, des- 
tination end points and channels cannot be dropped 
as part of the split operation. 20 

The originator of a merge opera&>n is required to 
be a member both MMVCs to be merged. Similarly, 
the originator of a split operation is required to be a 
member of both of the resulting MMVCs. 

25 

User Interface 

There are three levels of windows presented to 
the conferees of a workstation: Ul windows, room win- 
dows and application windows. A UI window has 30 
menus to (1) ^tup and tear down multiparty (or two 
party) conference calls, (2) add, and delete ar^li- 
cations in a o^erence call, (3) merge and split con- 
ference calls, and (4) record a oonfiBrenca. 

There Is a room window for each conference call 35 
from orto a workstation. Each room window contains 
applications and conferees of a conference. Since a 
workstation may have multiple conferences, a room 
window provides a graphical view of each conference 
and Its components. Access control is provided 40 
through a room window. 

There are application windows which appli- 
cations aeate. Usually an apr^ication window con- 
sists of a top level window which contains other 
subwindows inside its txHjndary. For each application 4S 
in a conference, an application window wOi appear In 
each station which participates in this conference. 
The application window is the place where shared 
data from applications are displayed and is where the 
commands to the application are input 60 

When Ul starts to run, itdoes two things: (1) starts 
a listen process to listen to inconrdng call requests 
from orher workstations, and (2) displays a main 
menu to accept user commands. The main menu is 
shown in the FIG. 16. The main menu has two rows 55 
of command buttons and a face icon which identrfies 
tiie conferee's workstation. The buttons in the top row 
represent operations on conference rooms and 



objects in conference rooms. An object may be an 
application or a conferee. The buttons in the sacond 
row are used to create objects (applications) in a 
room. The command buttons firom left to right In ttte 
first row are: room button, quit button, record button, 
trash button, rrterge button and spitt button. The conrv 
mand buttons in the second row are: directory button, 
phone button, Icsh button, X button, and cut— paste 
button. In tins user interface, a command button (or a 
window) is selected by positioning the cursor on tiie 
t>uttDn (or tiie window) and pressing tiie left most 
mouse button. The use of the conrtmand buttons to 
construct a conference configuration is now des- 
oibed. 

To set up a corrference, a conferee first creates 
a room by sheeting tiie room button. Aroom wftii only 
the originating conferee icon in the room wSI appear. 
Each room has a room window and a room identifier 
window (which on the top of the room window). 
Each room tes a unique room klentffter shown in ttte 
room identifier window. When the directory button is 
selected, Ul wOi display a directory which contains 
^ce Icons (FIG. 18) representkig all tiie people that 
can be reached from this workstation. To make a call, 
the orlginat&tg conferee puts other conferees Into the 
room by first selecting conferees and then selecting 
the room window. The Ul wfll initiate a call to tiie 
remote conferees by opening a mult&nedia virtual cir- 
cuit connection with conferee addresses as par- 
ameters. Iftiie connection is established successfully, 
the originating Ul win add the remote conferee icons 
into the nxm Otherwise, the room wSI only have the 
c^ginating conferee icon. If a call fiaSs, the originating 
conferee can try again by using the same procedure. 
If a call succeeds, the remote site workstetions wOi 
have a conference room which is the same as the con- 
ference room at the originating site. A conference 
room is said to be initially established when a call con- 
nection is estebllshed. The first face icon in the 
established roam is the originator and tiie remaining 
icons show the other parties tiiat are also in the con- 
ference. RG. 17 shows an established room with 
tiiree parties and FIG. 18 shows a directory. An 
estebllshed room with no applications has only one 
signalling channel In the connection. Ul uses this sig- 
nalling channel to communicate session layer mes- 
sages for this room. 

After tiie call has been estebllshed, applications 
can then be added kite the room. Unlike conference 
members, applications can be added or deleted 
dynamically. An application is added to a room by first 
selecting the application command button in the main 
Ul menu, and then selecting the room. When an applf- 
catton b added to (deleted from) a roofn, a channel is 
added to (deleted from) the existing connectfon. By 
convention, the first application added to a confer- 
ence room is a phone. Conferees can use voice com- 
munication for negotiating and for coordination the 
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Other applications to be added to the conference 
room. A phone icon wfll appear in the room when a 
phone is added to a room. The phone is inrttaily 
onhook. it goes offhook when the phone icon in the 
conference room la selected. An access control menu 
with phone options is displayed. aQowing conferees to 
operate their phones in different modes. 

Only one phone can be added to a room. How- 
ever, many data applications can be added to a room. 
There are two major dasses of data applications tl^t 
can be used in the present embodiment traditionai 
character-based applications and graphicrbased X 
applicationa These applications are ^ically wrftten 
for a single user. For adding traditional character-ba- 
sed appilcaiions, conferees select the ksh button first 
and then the conference room window. A Icsh icon will 
appear in the room and a ksh application window 
which is oeated by the ksh applteation process will ^ 
also appear on the display. Tradittonal character-ba- 
sed application can then be invoked through the ksh 
applicatk>n window. To link the icon to the application 
window, the icon has a unique name assigned by Ul 
which will also be the title of the application window 
and whk>h will appear in the titie bar. 

For X applications, a directory menu Is provkied 
when the X button is selected. Conferees select an 
applicatton from the menu and select the room to 
create the appiicatk>n in that room. Similar to ksh 
applicattons, an Icon and an application window will 
appear when an X application is added to a room. 

The cut-pasto button is used to add a cut-paste 
application to a room. The cut-paste program ads like 
a chalkboard whteh allow conf^iee to cut images from 
other windows in the display Into the cut-paste appO- 
catk)n w^dow. it also allow conferees to erase (cut- 
out) images from the cut-paste window. RG. 19 
illustrates a dbplay for a conference room having a 
phone, a ksh applk:atk)n. and an X application (ez 
editor). 

For applications invoked from the ksh button and 
from the X button, a single copy of the program runs 
a the station where the appPicatton is invoked. A point- 
to-multipoint channel with upstream capability is 
needed for these appik^ations. For cut-paste appli- 
cations, each stetion mns Ite own copy of the prog- 
ram. A mulfipoint-to-multipoint diannel is needed for 
this tmplementetion. 

Any appllcatton can be deleted firom a conference 
room by selecting the trash button and then selecting 
the application icon in the room. The application loon 
and the applicatk>n window will disappear when an 
application is trashed. The channel associated with 
that application will also be deleted. The trash button 
can also be used to terminate a conference room by 
selecting the room identifier window. When a room is 
trashed all applications are deleted first, then the vir- 
tual circuit connectton is terminated. The quit button 
Is used to exit the user interfece and terminate all 



ongoir^ conferences. 

In most conference sitoations, when an appll- 
catk)n is shared, all conferees should have the same 
right to receive outpute from the applicatton and to 

5 input commands to the application. In son>e situa- 
ttons, the Input or the output of an applicatkm may be 
restricted due to security, application features or 
implementation requiremente. There are nrany situa- 
tions that access contrd wQI be usefuL For example, 

10 one may share some private date with a subset of 
conferees during a period of time. Another example is 
if one IS participating In two conferences, he/she may 
alternatively Hsten and talk on one conference and lis- 
ten on arxJther conference. The control of a conferee 

IS transmitting to or receiving from an application Is cal- 
led access control. The capabOity fx a conferee to 
access a shared applteatton is called the conferee's 
access capability. An access control policy describes 
how to assign access capabilities and how to change 

20 access capablities. 

There can be n^ny polk^ for access control. In 
the present embodiment, the transport lay^ software 
can be requested by the software above to discard 
incoming packets firc»n a particular conferee on a par- 

25 ticular channel Thts mechanism is used to implement 
access control. The transport layer is flexible to allow 
other access control policies. 

The access capabOtty basically has tour levels: 
input and output, output only, input only and no k>. For 

30 the phone application, these four levels translate to 
hear and talk, hear only, talk only (can't hear) and 
neither hear nor talk. We define a strict order on the 
degree of control on these four levels: Input and out- 
put has the highest order and no lo has the lowest 

35 order. Our access control pdfcy b as fdtows. When 
an application is added to a conference room, each 
conferee Is gh^en a maial access capability and a cell- 
ing access capability based on the type of the apptt- 
cation. Fora phone applkation, the initial capability Is 

40 no to for each conferee (equivalent to onhook) and the 
ceRing capability is input and output For ksh and cut- 
paste appiicatbns, each conferee has input and out- 
put initial capability and ceDing capability. For X 
applications, the controller has input and output initial 

45 and ceDing capabilities. All others have outputonly ini- 
tial and ceaing capability. The capabQity levels 
implemented for each appiicattons are different firom 
application to applk:atk)n. Phone has all four levels. 
Ksh and cut-pasto has three levels: input and output, 

50 output only and no to. X appiicattons only have two 
levels: input and output and no io. 

Only the controller can change another con- 
feree's ce3ins capability. When the controller moves 
a conferee's cun-ent capability, the new level 

55 : becomes the cefling capabfflty of that conferee. 

A conferee can change his/her own current 
capabQity to a lower or a higher capability level. A con- 
feree can move to a higher level as long as that level 
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does not exceed his/her own ceQing capabOiiy. When 
a phone application is added to a room, ft is Ir^lly 
onhook (no lo}. Each conferee needs to change the 
capabQity to input and output in order to have voice 
conference. 5 

To change the capabDily* a conferee first select 
the application Icot in the conference room. An 
access control window will appear. The access con- 
trol window shows aD the conferee icons and all poss- 
ible access capabnity levels are shown on the right io 
side of the conferee icon. The current access capabi- 
lity level (not the ceQing capabflity} is highlighted. FIG. 
20 and RG. 21 show the access control windows of 
phone and ksh respectively. By selecting the access 
capabOity level provided in the access control window, iS 
a conferee can change the current access capability. 
The penmission to change capabOrties is always 
checked by the UI according to the policy mentioned 
above. If the change is not pennftted, the cunrent 
capabiitymll not be changed. Conferees can always so 
select any application icon to review the capafcrilities 
of that application. Forttie phone application, the cur- 
rent capability is also rdlected in the phone icon In the 
conference room. 

The record button provides real time conference 2S 
recordingt midtimedia document review and anno- 
tation. When the record button is selected, a play-re- 
cord rrmu window will be displayed (FIG. 22). The 
play-record menu window has five options: play, 
record review, anot, and stop. To record a conference, so 
it is assumed that the conference room has a phone 
application and a ksh applk:atton. When a conferee 
selects the record option, a query window wOi appear 
to input the file name to t>e recorded to and the ksh 
application to be recorded firom. To start the recording 3$ 
process, the conferee needs to give thefile path name 
(or use the default file name) and selects the ksh 
ap^ication icon from a conference room. The voice 
packets from the phone and the data packets from the 
ksh application are multiplexed together and stored 40 
into the given file. The temporal relationship is main- 
tained when this multimedia fOe is played back. 

The stop button is used to stop a conference 
recording. When stop is selected, the play-record 
menu window will disappear. To play back a recorded 45 
file, the record button is used to display a play-record 
window and then the play option Is selected. Sbnilar 
to the recording, a query window is popped up to Input 
the file name and the ksh to play the multimedia file. 
When playing a f3e, text data will appear on the ksh so 
application window and voice packets w3l be sent to 
the voice handset The play option Is used to play a 
recorded fOe into a conference room, so % assumes 
that the room has a voice application and a ksh appli- 
catton. A review option is provided to let a conferee 55 
review a document locally. When review is selected, 
a query window wll be displayed for a conferee to 
input the fie name and a ksh window will be created 



to review the given fDe. The ksh application does not 
belong to any conference room. During the review 
process, vdce annotation can be invoked by selecting 
the anot option. Selecting the anot button wi!l start the 
annotatk^n. Voice packets will be inserted into the 
multimedia file. Selecting the anot again wHl stop the 
annotation. Voice annotation can also be made while 
playing a recorded file. 

One major design consideration of the user inter- 
face concerns perfonnance of real time conference 
operations. In addition to adding/deleting applications 
to/from a conference, the conference operatbns pro- 
vided are: merging two conferences into one confer- 
ence, and spitting one conference into two 
conferences. The notion of a conference room Is used 
to represent a conference. Each conferee and each 
application Invoh^ed in a conference are represented 
in the conference room by a icon. For desktop confer- 
ences, the conference room representetion is a con- 
venient way to perfonn real time conference 
operations. 

When a conferee want to split a conference, 
he/she first selects the split button and then selects 
the conferance room to be split t>y selecting the room 
Identffier window. UI will display a splitting menu win- 
dow and a new conference room* FIG. 23a illustrates 
a splitting menu, FIG. 23b a room which is being split, 
and RG. 23c a new conference room. The new con- 
ference room wiQ have a new Mentifler and the origi- 
nating conferee icon In it A splitting menu window has 
four selections: move, copy, abort and don& 

An applicaUon or a conferee can t>e copied or 
moved into the new conference room. When a con- 
feree is copied, it means the conferee wOl participate 
in botii the original conference and the newly created 
conference. When an appiicatton is copied, the origi- 
nal application process will be kept for the original 
room and a new application instance will be created 
for the new conference room. The contents of the 
original application window will not be copied into the 
new application window. When a conferee is moved 
to the new room, he/she will no longer remain in the 
original conference. When an application Is moved 
into the new room, the original application may t>e 
deleted ftom a conferee's workstatton If the conferee 
Is not in the new room. The originating conferee uses 
move and copy selecticms repeatedly to construct the 
new configuration clthe original conference room and 
tiie new conference room. The at)ort menu aborte the 
split process. The done menu informs UI to stertthe 
splitting process. The Ui will not call the networic to 
split the virtual drcuit connectton unless the done 
menu is selected. The originating UI needs to inform 
; each remoXe UI how the conference room will be spilt 
before or after splitting the virtual circuit Voice com- 
munication is assumed to be importent for conferees 
to coordinate t)Oth the split and the merge operations. 

If the network spirt operatton is successful, the 
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Merge and Split Protocol 

In one alternative omplementatlon of a merge and 
split protocol, a merge or split request is transmuted 
Into the network, and the request is propagated 
through the network nodes, finally delivering the 35 
request at all invoWed workstations. However, the 
merge and spl% operations cause alterations in the 
connectivity of the original MMVC(8) and the data 
structures associated with the MMVC(s}. If a 
merge/split operation is committed to using a single 40 
phase protocol, as described above, then it is imposs- 
ible to ensure that failure of the operation will not dis- 
rupt the original MMVC. For example, envision a 
merge request sent into the network. One node in the 
networks accepts the request, updates it data struo- 45 
tures and forwards the request on to the next node. 
Unfortunately, the second node does not have ttte 
resources to complete the merge and thus denies the 
request In this case the original MMVCs can not be 
recovered, since the first node has already committed so 
to the operation; there is no alternative but to dearthe 
MIWVC. This is disastrous for the user, not only is his 
request denied but his previousiy stable connection is 
destroyed. 

For this reason, the prefen-ed embodiment is a 55 ^ 
two phase protocol. The protocol minimizes the effect 
of a faOed operation on the user. The first phase of the 
protoccd is used to determine if all components, that 



is woric-stab'ons and network nodes, agree to conv 
plete the nnerge or split operation. When the works- 
tation originating the operatkm detemtines that all 
components have agreed to the operatkin, it initiates 
the second phase of the protocol issuing an accept 
message. The accept message indicates that aS conv 
ponents ^ould complete the merge orspHtoperatton. 
If any component denies the requested operation dur- 
ing the initial phase, then the original MMVC(s) are 
unaffected. 

The preferred protocol is shown in RG, 25. The 
'mrg/spl^nquiry" is a sessbn layer to session layer 
communication. The "iocti (mrg/split)*. represents an 
k>cti call made by the session layer requesting a 
merge or split be inflated the transport layer. 

Once the transport layer receives a merge or split 
conrvnand via an Iocti caB, it sends a merge or split 
request (denoted wnMrg/wnSpIt in RG. 25) into the 
networtq the latter acknowledges the receipt of the 
packet When a wnMrg or WnSplit packet is recehmd 
at an endstation, & is Immediately acknowledged t^ 
the transport layer with a wnAck packet This only Indi- 
cates that the packet was received at the endstation. 
The receipt of a wnMrg or wnSplit also causes a ses- 
sion layer listen process to be given a merge or s(^tt 
request message. The listen process in tum issues a 
merge or split iocti call on the far end workstatkm. The 
transport layer of each far end workstation then sends 
and end-to-end acknowledgement to the origkiating 
woricstation, indicating that they agree to the 
merge/sptit request 

Once the originating workstation has received an 
end to end acknowledgement from all participating 
workstatkans. a wnMaccept or wnSaccept packet is 
issued. The accept packet indicates that all ends- 
tations have acknowledged receipt of the merge or 
split request and each station agreed to the merge or 
split command- Thfe packet ads as a commit; after 
being sent the merge or split comnrtand can not t>e 
aborted. Upon receiving this packet the far end work- 
stations send an end-to-end acknowledgement and 
then return from the toctJ can. The second set of end- 
to-end acknowledgements are used to indicate when 
the originating workstation can return from the iocti 
call. Once ttiese acknowledgements are received all 
connections are established and packet transfer can 
begin immediately. 

It is to be understood tiiat the above-described 
embodiments are merely illustrative of the principles 
of the invention and that many variations may be dev- 
ised by tiiose skilled in the art wittiout departing from 
the spirit and scope of the invention. It is therefore 
intended that such variations be included wititin the 
scope of the claims. 



original connection will be split into two connections, 
in tiie connection for the original room, the channels 
used by tiie apF^ications which have been moved are 
closed. In tiie connection for the new room, new chan- 
nels are created if new application instances are s 
created. RGS. 24 AND RG. 24b show the room con- 
figurations after tiie phone is copied, and ttie ksh 
application and a conferee are moved from the origi- 
nal room. 

Merging is an inverse process of splitting. To io 
merge two conferences, the originating conferee first 
selects the merge button and then selects the two 
rooms to be merged In order, the merge-from room 
and the merge-to room. When two conference rooms 
are merged, all conferees in these tm rooms wilt be is 
merged into tiie merge-to room. Exceptfor the phone, 
all applications from the merge-from room wi8 be 
added to the merge-to room. If both rooms have 
phones, then only tiie phone in the merge-to room is 
kept If a station only has tiie merge-from room, the 20 
merge-from rocnn wiB be modifi^ into tiie merge-to 
room. This means that applications already running 
will be kept (except pos^bly phone application} and 
applications from the merge-to room wSI be added. If 
a station only has a nneige-to room, the Ul wQl perfomfi 2S 
a similar task. If a station has two rooms, ail tiie appli- 
cattons will be kept (except only one phone channel 
is kept). 
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Claims 

1. A method for use in an arrangement comprising 
a communication network interconnecting a 
plurality of user stations, said method comprising s 

providing a first call among a first set of 
said us^ stations, 

providing a second call among a second 
set of said user stations and 

merging said first and second calls into a to 
single call, comprising a plurality of channels, 
among at least three user statbns from said first 
and second sets, said plurality of channels corre- 
sponding to a combination of channels of said first 
and second calls. f< 

2* A method in accordance with claim 1 wherein said 
merging comprises 

merging said first and second calls into a 
single caQ connection, comprising said plurality of 20 
channels, among the union of said first and sec- 
ond sets of user stations. 

3. A method In accordance with claim 1 wherein said 

fust call comprises a signaling channel, said seo- 25 
ond can comprises a signaling channel, at least 
one of said first and second caQs further conv 
prises at least one non^ignaltng channel, and 
said plurality of channels comprises a ^gnallng 
channel and at least one non-signaiing channel. 30 

4. A method in accordance with claim 1 wherein said 
first call comprises at least one data channel, said 
second call comprises at least one data channel, 

and said plurality of channels includes a data 35 
channel fc^ eadi data channel of said first and 
second calls. 

5. AnnethodinacconJanc6Wlthclalnn4wherelnat 
least one of said first and second calls further 40 
comprises a voice channel, and said plurality of 
channels further includes a voice channel. 

6. Amethod in accordance with d^Swherelnsaid 

first call further com^ses a signaling channel, 45 
said second caQ further comprises a signaling 
channel, and said ptwality of channels further 
includes a signaling channel. 

7. A method In accordance with claim 4 wherein at 50 
least one of said first and second calls further 
comprises an image channel, and said plurality of 
channels further Includes an Image channel 

8. A method in accordance with Claim 4 wherein at 55 
least one of said first and second calls further 
comprises a video diannel, and said plurality of 
channels further includes a video channel. 



9. A method in accordancewithdaimi wherein said 
plurality of diannels comprise virtual channels of 
a multicast oonnectioa 

10. Amethod in accordance with daim 1 furtherconv 
prislng In response to user Input, selectively pro- 
viding said at least three user stations with 
access to transmit infonnation to and receive 
information from said plurality of diannels. 

11. A method in accordance with datm 1 wherein at 
least one of said first set of i^er stations and at 
least one of said second set of user stations 
include display means, said method further ccmv 
prising 

In response to user input at said one of 
said first set stations, both establishing said first 
call in said networic and displaying represen- 
tations corresponding to said first set of user sta- 
tions in a window on said display means of said 
one of said first set stations, and 

in response to user input at said one of 
said second set stations, both establishing said 
second call in said networic and dls^Haylng repre- 
sentations corresponding to said second set of 
user stations in a window on said display means 
of said one of said second set stations. 

12. A method In accordance with dalm 1 wherein one 
of said plurality of user stations is a nr^mber of 
both of said first and second sets, said one user 
station contprises display means, said merging is 
in response to user input at said one user station, 
said method further comprising 

further in response to said user Input at 
said one user station, displaying representations 
corrasponding to user stations of said first and 
second sets in a window on said display means. 

13. A method In accordance with daim 12 further 
comprising 

further In response to said user Input at 
said one user station, displaying. In said window, 
representations each corresponding to one of 
said plurality of ctannels. 

14. A method in accordance witti daim 12 wherein 
said plurality of channels Indudes at least one 
data channel, said method further comprising 

displaying, in a second window of said dis- 
play means, a data communication application 
• shared annong userstatfons of said first and sec- 
ond sets via said one data channel. 

15. A mettiod in accordance with dalm 1 wherein one 
of said plurality of user stations is a member of 
both of said first and second sets, said metiiod 
further comprising 
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in response to user input at said one user 
station, transmitting a merge request via said net- 
work to each of the other user stations of said fiist 
and second sets, and 

in response to receipt of a fevorable reply s 
to said merge request from each of said other 
user stations of said first and second sets, ^id 
one user station initiating said merging. 
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